Go to Home Page
Questions?
Call 1-800-572-5517
 
  Go to Home Page  
  See all products
  See price schedules
  See manuals, tutorials, articles
  Download a free 30-day trial
  See user testimonials
  About Pacific Systems Group
 
 
SMF Tools
  See SMF Record Layouts
  See Sample SMF Reports
  Learn How to Export SMF Data
  Download Free SMF Reporting Software (30 days)
 
One of the greatest SMF record parsing programming languages I've ever seen. Chief, Large Systems Services Branch, NIH
  Choose Spectrum Writer to add 4GL to your product
  Report Writer Speedup Tips Article
Spectrum SMF Writer - the 4GL SMF Report Writer.

Add customized reports and PC export files to your product!

Table of Contents

NOTE: you can find this and other lessons in a
more complete and viewable format (including all Figures) in our Tutorial PDF.

Lesson 4. How to Report on Multiple Occurrences of an SMF Section

  1. This lesson teaches you how to report on data in sections of an SMF record that occur more than one time. The control statement discussed is
  2. the NORMALIZE parm of the INPUT statement
  3. As you probably know, SMF records are notorious for the complex way in which they are assembled. Many commonly used SMF records consist of numerous different sections, each containing an entirely different set of data. For example, here is a list of just some of the sections found within the SMF 30 record:
  4. Subsystem Section
  5. Identification Section
  6. I/O Activity Section
  7. Completion Section
  8. Processor Section
  9. EXCP Section
  10. Complicating matters further, certain sections may appear in some SMF 30 records but not in others. Furthermore, when a section does appear in a record, it may not be in the same location in all records. And finally, some of these sections can occur more than one time within a single SMF 30 record. And the number of times that it occurs varies from record to record.
  11. Did we mention that each occurrence of such a multiple-occurring section can contain nested sections of its own (which, yes you guessed it, can also occur a variable number of times).
  12. It's no wonder SMF records present a real headache to most report writers. And especially to programmers coding their own programs to parse SMF records.
  13. But this is just where Spectrum SMF Writer shines! It has special functionality designed to handle even the most complicated SMF records. And it makes this almost transparent to the end user (you).
  14. Most of the work involved in handling these situations has already been done for you right in the file definitions. (Feel free to browse the definitions in the copy library to see how we use OFFSET parms and conditional COMPUTE statements to determine whether a section exists in a given record, and if so where it is located.)
The Famous "Triplets"
  1. IBM uses what it calls "triplets" to unravel the layout of complicated SMF records. A triplet is three fields, which are usually at a fixed location within the SMF record. (But not always. When dealing with nested sections, their triplets are usually embedded within the parent section, which must first be located using its own triplet.) The three fields in a triplet specify:
  2. the offset to the beginning of the first occurrence of the section
  3. the length of each occurrence of the section
  4. the number of times that the section appears in the SMF record. (This number may be zero, indicating that the section is not present at all in that record.)
Reporting on Data from the First Occurrence of a Section
  1. Spectrum SMF Writer includes the definitions of the triplets in its file definition (in the copy library). The file definitions also define the first occurrence of each field within each section, using the information from the appropriate triplet.
  2. That means that no special action is required on your part to report on the data contained in the first (and often only) occurrence of any section. Just name the fields on your COLUMNS statement (or other statement) just like any other field.
  3. And there are actually many sections that do occur only one time. For example, the Subsystem and Identification sections in type 30 records always occur exactly once in every SMF 30 record. And the I/O Activity, Completion and Processor sections each occurs either once or not at all.
  4. Consider these statements:

INPUT: SMF30 /* COPY SMF 30 RECORD DEF */
INCLUDEIF: SMF30RTY=30 AND SMF30STP=5 /* SELECT TYPE 30 SUBTYPE 5 */
COLUMNS: SMF30DTE SMF30TME SMF30RTY SMF30STP SMF30JBN
SMF30INP SMF30SCC(HEX) SMF30DDN SMF30BLK SMF30BSZ

  1. The above statements produce the report shown in Figure _. That report uses just the SMF 30 records written at job termination time (the subtype 5 records.) The report has columns for these items taken from various parts of the SMF 30 record:
    2. SMF 30 report with data from only the first occurrence of various section
    SMF 30 report with data from only the first occurrence of various section
     
  2. log date and time, record type and subtype (all from the standard SMF record header)
  3. job name (from the Identification section, which occurs exactly once)
  4. number of card image records read (from the I/O Activity section, which occurs no more than once)
  5. step completion code (from the Completion Section, which occurs no more than once)
  6. DDNAME , EXCP block count, and largest block size (all taken from the EXCP section, which can occur any number of times)
  7. The report in Figure _ shows the contents of those fields taken from the first occurrence of each section (even though that first section may be located at different offsets in different records.)
  8. if you refer to a field in a section that does not exist in a record, it is treated as "missing." Missing fields yield blanks or zeros, depending on the data type.
Reporting on Data from All Occurrences of a Section
  1. Now let's look at the more complex case. As noted, the EXCP section can occur from 0 to "n" times in an SMF 30 record. Specifically, there is one EXCP section in the SMF 30 record for each DDNAME used by the job.
  2. But the report in Figure _ only shows the DDNAME , EXCP count and maximum blocksize for a single DDNAME for each job. (Whichever DDNAME the SMF system happened to put in the first occurrence of the EXCP section.)
  3. To report on the DDNAME , the EXCP count and the maximum block size for each DD in the job, you'll just need to add an additional parm to your INPUT statement -- the NORMALIZE parm:

INPUT: SMF30 NORMALIZE(SMF30_EXCP_SECTION, SMF30EON)

NORMALIZE Parm Syntax
  1. Let's look at the syntax of the NORMALIZE parm. It contains two fields:
  2. the name of the section to be normalized. This must be a character field that encompasses the whole section. In this example, we normalized a field called SMF30_EXCP_SECTION . If you look in the copy library, you will see that is a 30-byte field that contains the whole EXCP section. By normalizing that field, all of the smaller fields defined within that area are also normalized. In our report, we use three of those fields: SMD30DDN , SMF30BLK and SMF30BSZ .
  3. the number of times that the EXCP section occurs within the record. This value can be a numeric literal, a numeric field name (as in this example) or a numeric expression. The SMF30 record has a field named SMF30EON (part of a triplet) which specifies how many occurrences of the EXCP section exist in the record.
  4. The NORMALIZE parm is usually used in conjunction with the NORMWHEN parm (as shown in Figure _). The NORMWHEN parms tells Spectrum SMF Writer when to perform the normalization described in the following NORMALIZE parm(s). (If we had omitted the NORMWHEN parm, Spectrum SMF Writer would have tried to normalize the EXCP section on every input record, not just the type 30 SMF records. This could lead to errors, since the triplet that Spectrum SMF Writer uses would contain "garbage" for the non-type 30 records.)
What the NORMALIZE Parm Does
  1. You can read a detailed explanation of the NORMALIZE parm in Chapter 4, "Beyond the Basics" (on page 237.) Briefly, the NORMALIZE parm causes Spectrum SMF Writer to process a single SMF record as if it were multiple "logical" input records. Each of those logical records can be treated as having a single occurrence of the EXCP section, relocated to the first section location within the record. The result is the same as if the SMF file actually contained one SMF 30 record for each DDNAME used by a job. (That, by the way, is the way that the similar SMF 14 records really are logged -- one record per DD .)
  2. Here is an example of using the NORMALIZE parm to process all occurrences of the EXCP section of the SMF 30 subtype 5 records.
    3. SMF 30 report with data from all occurrences of the EXCP section
    SMF 30 report with data from all occurrences of the EXCP section
     

INPUT: SMF30 /* COPY SMF 30 RECORD DEFS */
NORMWHEN(SMF30RTY=30 AND SMF30STP=5) /* WHEN TO NORMALIZE */
NORMALIZE(SMF30_EXCP_SECTION, SMF30EON) /* SECTION NAME, HOW MANY TIMES */
INCLUDEIF: SMF30RTY=30 AND SMF30STP=5 /* SELECT JUST TYPE 30 SUBTYPE 5 RECORDS */
COLUMNS: SMF30DTE SMF30DTE SMF30RTY SMF30STP SMF30JBN
SMF30INP SMF30SCC(HEX) SMF30DDN SMF30BLK SMF30BSZ

  1. The INPUT statement now has a NORMWHEN and a NORMALIZE parm. The other control statements haven't changed at all (from the previous report).
  2. The above control statements produce the report in Figure _.) That report shows data for all of the EXCP sections in the type 30 records. (Notice that the data from the other sections, which all occur only once, is the same in all of the logical EXCP records.)
What Section Names Should You Use
  1. We have made it easy for you to normalize the various SMF record sections that occur more than once. Just look at the file definition for the SMF record you are interested in. You can find the definitions in the copy library. There is a comment box before each section that is eligible to be normalized. In the comment box we show the NORMWHEN and NORMALIZE parms to use in order to normalize that particular section.
  2. Since the different sections within a record contain totally different sets of data, in most cases you will just want to normalize a single section for any given report. (In the much the same way that we normally include data from only a single SMF record type in a given report.)
  3. Spectrum SMF Writer, however, does support the normalization of more than one section at a time. And we will discuss that in the section that follows.
How to Normalize Multiple, Nested Sections
  1. There is one case where it actually does make sense to normalize multiple sections in the same report. And that is when one section contains an embedded section. In that case, you may well want to first normalize the outer section, so your report includes all occurrences of that section. And then for each of those occurrences you would also want to see all occurrences of the section that is embedded within it.
  2. The SMF 70 record ("RMF Processor Activity") provides just such a situation. So we will use it for an example. In the fixed portion of the SMF 70 (subtype 1) record there is this triplet: SMF80BCS , SMF80BCL , and SMF80BCN . These fields define an "LPAR Partition Data Section" which occurs once for each configured logical partition.
  3. Within this LPAR Data Section, there are two additional fields ( SMF70BDN and SMF70BDS ) which when used together with an additional triplet ( SMF70BVS , SMF70BVS , and SMF70BVS ) identify some number of LPAR Processor Data Sections which contain information about each logical processor for the associated logical partition.
  4. Have we lost you yet?
  5. The main idea to pick up here is that if the need arises, you can report on all occurrences of nested recurring sections. And the part that you do need to understand is very easy: to NORMALIZE nested sections, you simply add an additional NORMALIZE parm to the INPUT statement:

INPUT: SMF70
NORMWHEN(SMF70RTY=70 AND SMF70STY=1)
NORMALIZE(SMF70_PRSMPD_SECTION, SMF70BCN) /*PARTITIONS */
NORMALIZE(SMF70_PRSMLPD_SECTION, SMF70BDN) /*PROCESSORS */

  • we did not need to add an additional NORMWHEN parm. The existing one applies to all NORMALIZE parms that follow it.
  • With this INPUT statement, Spectrum SMF Writer will process each physical SMF 70 (subtype 1) record as a multiple number of logical records.
  • You might think of this as processing each element of a two-dimensional array. While the first occurrence of the outer section is used, each occurrence of the inner section is normalized to form a logical record. After that, the second occurrence of the outer section is used, and all of the inner sections for it are normalized, and so on.
  • Don't worry if you this seems a little complex to you. It is complex. And happily, most SMF reports don't need such sophisticated logic. But it's nice to know that your SMF Report Writer can handle it if the need does arise. And just by adding a line or two to your INPUT statement.
  • You can see a report example that uses the above statement in Figure _.
Summary
  1. Here is a summary of what we learned in this lesson:
  2. add a NORMWHEN and a NORMALIZE parm to your INPUT statement to process all of the occurrences of a particular section in the SMF record?
  3. you can use multiple NORMALIZE parms to process nested recurring sections
  4. The next lesson will teach you how to customize the titles in your report.
To Learn More
  1. You can learn more about the normalization process in these places:
  2. a fuller explanation of the normalization process is found in Chapter 4, "Beyond the Basics" beginning on page 237
  3. the complete syntax for the parms related to normalization is found in (page 542).
Copyright 2024.
Pacific Systems Group.
All rights reserved. 		Home | Products | Prices | Documentation | 30-Day Trials | Customer Reviews | Company | FAQ | Sample Reports | SMF Records
Send Your Comments or Questions